Reductions in the cost of computing coupled with virtualization and large-scale utility computing have resulted in ubiquitous computing resources and network connectivity, which has, in turn, resulted in new computing paradigms (e.g., cloud computing). Such Internet-scale computing resources can reduce the cost of operations for many applications. Cloud computing further provides a foundation for collaborative applications and a target for mobile platforms. Cloud computing is based on a scalable server platform suitable for handling computing loads of highly interactive collaborative applications, such as social applications and cloud-based office applications.
As Internet-scale computing infrastructure becomes increasingly affordable to mass-paid services, cloud computing users will seek matching affordability in software resources. Cloud computing resources can provide platform-as-a-service (PaaS) products, including software and product development tools hosted within the cloud infrastructure. Alternatively, software-as-a-service (SaaS) cloud models include software products interacting with users through a front-end portal. In such environments, users will desire software functionality in an affordable price range. Such users may be, for example, business users with limited training and/or experience in software programming, if any at all. Notwithstanding, the need remains for enterprise customers of cloud resources to be able to configure software in a manner appropriate to their needs.
Historically, creation of software has been approached from the perspective of the computer. Most software is expressed through use of general purpose programming language. Thus, programs are focused on what is required of the computer (e.g., execution details), rather than the problems that the software is developed to address. Addressing changes to the problem or desired solution is thus effected by modifying the program's code. But the general purpose programming languages used to write software are just that—general—and so were not created to clearly express a specific problem to be solved. This makes writing such software, as well as making subsequent modifications (e.g., to reflect changes in the problem addressed thereby), a difficult task.
The people most familiar with the problem to be solved are those who use the software in their particular problem domain. Domain experts are familiar with the issues, concepts, and definitions that need to be satisfied in the problem domain. On the other hand, software programmers have expertise in software creation and, with the domain experts, traditionally work to generate software. This division of labor and expertise inevitably leads to frustration in one or both parties, as changes in program specifications and the complexity of the problem domain are understood by the domain expert, but cause numerous rewrites and revisions on the part of the programmer. Similarly, misunderstandings on the part of the programmer regarding the description provided by the domain expert can lead to frustration on the part of the domain expert.
FIG. 1A is a simplified block diagram illustrating a traditional software development workflow. A domain expert 105 communicates a problem statement to a programmer 110. This is typically done using forms that cannot be automatically transformed into code, such as specifications, use cases, stories, notes, sketches and the like. Programmer 110 then uses the intentions thus described, together with the programmer's knowledge and expertise in software engineering, to create source code 115, which can then be executed by a computer. Changes to software for purposes of either maintenance or correctness must be defined in the problem statement provided by domain expert 105, and then be separately implemented by programmer 110. In order to extend or otherwise maintain a program, programmer 110 must disassemble the implementation, reason about the part in question, solve the problem and then reassemble the implementation, in order to achieve the desired result. This process of “taking apart” software and then putting the software back together can introduce programming errors and increase costs of the software.
In order to have software mirror the domain expert's intentions for the software, it is preferable to express the problem in domain terms. This necessarily requires a second step that takes the problem description made in domain terms and transforms that description to a software that a computer can execute, that is, program generation. While a programmer can write code in a fashion that uses terminology familiar to the domain problems addressed by the software, such programming can prove difficult in large systems, with a domain having a complex vocabulary, and in other such circumstances.
In light of the foregoing, and to accommodate user's need for enterprise-class cloud programming facilities, it is therefore desirable to provide such users with application development environments that are (1) simple enough to be used by users lacking extensive programming training and/or experience, and (2) sufficiently easy to customize, both to match the skills of such users and allow for efficient customization. Further, such application development environments should allow application customization to be performed in a manner that does not interfere with other users' access to the cloud resources involved (e.g., the application(s) being customized).